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This  report  was  prepared  under  the  auspices  of  the  Dam  Safety  Task 
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The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication, 
or  promotional  purposes.  Citation  of  trade  names  does  not  constitute  an 
official  endorsement  or  approval  of  the  use  of  such  commercial  products. 


Summary 


This  report  was  developed  by  Major  Alberto  Tavares  da  Silva,  a  Brazilian 
Army  Officer,  working  at  Geotechnical  Laboratory  (GL),  U.S.  Army  Engi¬ 
neer  Waterways  Experiment  Station  (WES),  between  August  1994  and  August 
1995  as  part  of  a  Brazilian  and  U.S.  Army  interchange. 

Major  Tavares  has  a  civil  engineer  graduate  degree  and  a  computer  science 
masters  degree.  His  work  at  CEWES-GS-S  includes  instrumentation,  moni¬ 
toring,  and  safety  of  earth  dams.  This  subject  is  a  matter  of  Brazilian  Army 
interest  because  of  dam  construction  in  the  northeast  of  Brazil,  a  very  dry 
interior  area. 

His  computer  science  specialization  area  is  that  of  software  engineer. 

These  two  powerful  software  tools  are  applied  to  generate  a  basic  structured 
documentation  to  the  Corps  of  Engineers  National  Dam  Inventory  Data 
Update  Program,  developed  at  CEWES-GS-S  by  Mr.  Earl  V.  Edris,  Jr., 

Ms.  Wipawi  Vanadit-Ellis,  and  Ms.  Kay  Woo,  GL. 

This  work  was  developed  under  the  guidance  of  Mr.  W.  M.  Myers,  Chief, 
Soil  Mechanics  Branch,  GL. 


Introduction 


This  Structured  Project  is  a  universal  methodology  that  enabled  the 
development  of  a  computer  system  within  a  life  cycle  as  shown  in  Figure  1 


Figure  1 .  System  life  cycle 


A  resume  of  each  phase  is: 

•  Survey. 

At  this  phase,  a  preliminary  study  of  the  system  is  developed.  The 
objective  is  to  approve  or  disprove. 
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•  Analysis. 


Two  methods  can  be  applied  at  this  phase:  Essential  Analysis  and 
Structured  Analysis.  Both  methods  use  the  data  flow  diagram  for  function 
modeling  and  entity-relationship  for  data  modeling.  Each  method  has  a  logi¬ 
cal  abstraction  level.  The  basic  difference  is  in  the  analysis  strategy,  because 
the  Essential  Analysis  uses  the  event  concept. 

•  Design. 

The  tool  used  here  is  the  Structure  Chart.  This  chart  has  a  physical 
abstraction  level,  since  this  phase  proceeds  the  implementation  of  the  system. 

•  Implementation. 

The  programs  are  codified. 

•  Tests. 

The  acceptance  tests  are  realized. 

•  Installation. 

The  system  is  installed  for  operation  and  includes  the  all  life  system 
maintenance. 

Following  the  life  cycle  is  difficult  for  engineers  other  than  computer 
engineers,  because  the  documentation  is  very  extensive  and  the  maintenance 
time  is  very  high.  A  minimal  documentation  is  necessary  to  warrant  a  good 
understanding.  Imagine  one  system  with  3,000  code  lines  specified  only 
through  the  source  codes.  The  programmer  will  have  no  problem  if  he  is 
familiar  with  the  program.  However,  a  programmer  who  is  unfamiliar  with 
the  program  can  face  difficulty  with  a  change  in  some  of  the  code  lines.  A 
minimal  documentation  is  necessary  for  program  maintenance. 
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2  Objectives 


This  report  has  the  following  objectives: 

•  It  describes  two  basic  tools  for  program  development:  Entity- 
relationship  (E-R)  Diagram  and  Structure  Chart. 

•  It  generates  a  basic  structured  documentation  to  the  Corps  of  Engi¬ 
neers  National  Dam  Inventory  Data  Update  Program  based  on  the  E-R 
Diagram  and  Structure  Chart. 

•  It  presents  some  improvements  to  the  Corps  of  Engineers  National 
Dam  Inventory  Data  Update  Program  based  on  the  E-R  Diagram  and 
Structure  Chart. 
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3  Entity-Relationship  Diagram 


The  Entity-Relationship  (E-R)  diagram  is  a  data  modeling  tool  which  gen¬ 
erates  the  data  stores  or  files  that  will  be  used  by  the  programs  and  was  devel¬ 
oped  by  Peter  Chen,  author  of  Data  Base  Management.  Its  use  is  not 
mandatory  as  with  some  scientific  programs  that  need  no  data  stores. 

The  E-R  Diagram  is  a  powerful  tool  for  database  specification  based  on  a 
relational  model  and  is  composed  of  entities,  relationships,  attributes,  and 
keys. 


Entity 

This  program  has  existing  form  sets  that  discern  each  other.  Figure  2 
shows  the  entity  graphic  representation. 

Ex:  Real  object — >  place,  instrument,  dam,  etc. 

Person  — >  engineer,  student,  etc. 

Abstract — >  organization,  aptness,  etc. 


Attributes 

Entity  characteristics  are  attributes.  Figure  3  shows  the  attribute  graphic 
representation.  It  is  unnecessary  to  place  the  attribute  connections  in  the  dia¬ 
gram,  because  an  entity  with  many  attributes  can  generate  a  legibility  prob¬ 
lem.  It  is  only  a  didactic  representation. 

Ex:  Instrument  (numberins,  name,  height,  weight,  purpose,  manufacturer) 


Key 

An  entity  is  a  set  of  similar  things  or  people  called  elements,  but  the 
existence  of  two  equal  elements  should  not  be  justified  in  the  same  entity.  A 
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Figure  2.  Entity 


Figure  3.  Attributes 


necessary  mechanism  called  a  key  identifies  one  or  more  attributes  that 
distinguish  one  element  from  all  others.  If  the  key  is  composed  of  one 
attribute,  it  is  called  a  simple  key;  if  composed  of  more  than  one  attribute,  it 
is  called  a  compound  key.  In  Figure  3,  the  attribute  nwnberins  identify  the 
elements  of  the  Instrument  entity. 

The  understanding  of  the  key  attribute  explains  one  important  concept 
called  foreign  key.  A  foreign  key  is  a  key  attribute  at  one  entity  and  an 
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attribute  at  another,  as  illustrated  in  the  example  below.  It  is  a  fundamental 
concept,  because  it  generates  a  relational  link  between  entities. 

Foreign  key  example: 


Relationship 

A  relationship  represents  one  entity  association.  Figure  4  shows  a  relation¬ 
ship  graphic  representation  where  the  entities  DAM  and  INSTRUMENT  are 
related  by  the  relationship  HAVE.  The  relationships  can  have  their  own 
attributes  as  illustrated  in  Figure  4. 

Relationship  types: 

•  1:1 

Figure  5  shows  that  all  occurrences  in  A  correspond  to  0  or  1  occur¬ 
rence  in  B. 

Figure  6  shows  a  1:1  relationship  example  between  the  entities  ENGI¬ 
NEER  and  PROJECT,  such  as,  one  engineer  works  at  only  one  pro¬ 
ject  and  the  project  has  only  one  responsible  engineer. 

•  1:N 

Figure  7  shows  that  all  occurrences  in  A  correspond  to  0  or  N  occur¬ 
rences  in  B. 
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Figures.  Relationship  1:1 


Figure  8  exemplifies  a  1:N  relationship.  One  dam  has  relations  with 
more  than  one  element  of  INSTRUMENT,  but  each  INSTRUMENT 
element  has  relations  with  only  one  dam  element.  One  dam  can  have 
more  than  one  instrument,  but  only  one  instrument  can  be  installed  at 
a  dam. 
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Figures.  1  ;1  relationship  example 


Figure  7.  1  :N  relationship 


•  N;M 

Figure  9  shows  that  all  occurrences  in  A  correspond  to  0  or  N  occur¬ 
rences  in  B  and  vice  versa. 


Chapter  3  Entity-Relationship  Diagram 


Figure  8.  1  :N  relationship  example 


Figure  9.  N:M  relationship 


Figure  10  exemplifies  a  N:M  relationship,  i.e.,  one  INSTRUMENT 
has  a  relationship  with  other  elements  of  a  MANUFACTURER  and 
vice  versa.  Therefore,  one  instrument  is  produced  by  one  manufac¬ 
turer  and  other  instruments  are  produced  by  other  manufacturers. 

•  N:M:P 

Figure  1 1  shows  a  ternary  relationship  between  entities. 
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Figure  10.  N:M  relationship  example 


Figure  11.  N:M:P  relationship  example 


Files  Generation 

The  E-R  diagram  generates  a  logical  level  specification.  It  is  necessary  to 
transform  entities  to  files,  in  a  physic  level,  that  will  be  updated  by  the  func¬ 
tion  of  the  program  or  by  some  interactive  fourth-generation  language.  The 
file  numbers  generated  will  depend  on  the  relationship  between  the  entities. 
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•  1:1 

All  relationships  1:1  generate  two  files,  and  the  key  attribute  of  either 
entity  will  be  a  foreign  key  in  the  other. 

•  1:N 

Most  of  the  relationship  1:N  generates  two  files,  and  the  entity  with 
cardinality  N  receives  the  foreign  key,  according  to  the  examples  in 
this  chapter.  If  the  relationship  has  its  own  attributes,  it  is  necessary 
to  give  special  attention.  The  relation  can  generate  each  file  with  its 
own  attributes  with  the  keys  of  both  entities  related. 

•  N:M 

All  relationships  N:M  generate  three  files:  two  files  from  the  entities 
and  one  file  from  the  relationship  with  its  own  attributes.  The  keys  of 
both  entities  are  related  as  shown  in  Figure  12. 


Figure  12.  N:M  relationship  file  generation 


E-R  Diagram  Activities 

It  is  important  to  list  the  activities  that  will  support  enable  generation  of 
the  E-R  Diagram: 
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•  Entities  definition. 

•  Relationship  definition. 

•  Relationship  types  definition  (1:1  /  1:N  /  N:M  /  N:M:P). 

•  Attributes  and  keys  definition. 
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Structure  Chart 


A  graphic  tool  permits  decomposition  of  program  modules,  creates  a 
hierarchy  between  them,  and  describes  the  program  structure. 

The  components  of  a  Structure  Diagram  are  described  as  follows. 


Modules 

A  module  is  the  basic  building  block  of  the  program.  There  are  many 
kinds  of  modules.  The  most  common  are  procedure  and  function.  It  can  be 
defined  as  a  program  instructions  set  with  five  basic  attributes: 

•  Name:  identify  the  module. 

•  Input  and  output:  input  and  output  data. 

•  Function:  what  to  do  with  the  entrance  data  to  produce  the  output 
data. 

•  Logic:  logic  which  run  the  functions. 

•  Internal  data:  data  referenced  only  by  the  own  module. 

It  is  very  important  that  a  previously  written  or  a  preexisting  module  can 
be  stored  in  a  library.  Figure  13  shows  the  module  graphic  representations. 


Connections 

Connections  represent  the  hierarchy  between  modules.  Figure  14  shows 
module  A  calling  module  B. 


Chapter  4  Structure  Chart 


Figure  13.  Module  graphic  representations 


Figure  14.  Connection  between  modules 


Module  Communications 

The  module  communications  occur  through  input  or  output  data  that  flow 
between  modules,  and  they  are  called  input  or  output  parameters.  The  arrow 
indicates  the  flow  direction.  The  names  or  identification  given  for  data  flow¬ 
ing  as  parameters  to  and  from  subroutines  are  names  as  used  in  the  calling 
module.  Its  usefulness  distinguishes  between  parameters  that  are  elements  of 
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control  as  flags,  errors,  or  end-of-data  indicators.  A  small  dot  on  the  tail  of 
any  arrow  indicates  control,  a  sinall  circle  indicates  data.  Figure  15  shows 
the  passage  of  both  parameter  types. 


O - ^  DATA  PARAMETER 

CONTROL  PARAMETER 


Figure  15.  Module  communications 


Activation 

Activation  is  a  subroutine  calling  form  and  it  can  be: 

•  Unconditional. 

A  module  calling  is  executed  without  a  conditional  test. 

•  Conditional. 

A  change  in  the  logic  flow  execution  occurs  inside  the  module  caused 
by  a  conditional  test.  Figure  16  shows  a  selection  conditional  test. 

•  Repeatedly. 

A  module  calls  one  or  more  modules  through  an  inner  loop.  Fig¬ 
ure  17  shows  the  annotation  used  in  this  case,  and  it  is  important  to 
observe  that  only  the  repeated  modules  may  be  encompassed. 
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Figure  1 7.  Repeated  activation 


Connector 

Figure  18  shows  the  two  connector  types; 

•  Intern  connection  -  repeated  modules  at  same  page. 

•  Extern  coimection  -  repeated  modules  between  different  pages. 
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5  Application 


The  Corps  of  Engineers  National  Dam  Inventory  Data  Update  Program 
was  developed  at  the  U.S.  Army  Engineer  Waterways  Experiment  Station 
(USACEWES)  with  the  objective  to  inventory  all  dams  on  Army  bases  that 
meet  one  of  the  following  requirements: 

•  Greater  than  6  ft  high  with  a  maximum  water  impounding  capacity  of 
at  least  50  acre-ft. 

•  At  least  25  ft  with  a  maximum  water  impounding  capacity  in  excess  of 
15  acre-ft. 

In  this  chapter,  a  basic  structured  documentation  for  the  dam  inventory 
program  will  be  developed  to  show  that  the  E-R  Diagram  and  Structure  Chart 
are  tools  that  are  very  easy  to  use  and  very  powerful  modeling  tools. 


E-R  Diagram 

As  mentioned  in  Chapter  3,  the  E-R  Diagram  is  a  data  modeling  tool. 

Based  on  program  files  with  the  extension,  it  was  possible  to  construct  the 
database  E-R  model  that  enabled  an  excellent  data  overview.  Figure  19  shows 
the  E-R  Diagram  modeling.  The  relationships  aren’t  named  because  they  are 
1:N  without  their  own  attributes;  therefore,  they  do  not  generate  files  and  it  is 
not  obligatory  to  have  identification. 

The  entities  and  their  respectives  keys  and  attributes  are: 

•  Corps  (#id,  cwis,  div,  dist,  owner,  state,  county,  damname,  lake, 
river,  purpose,  type,  hydhgt,  crest,  maxcap,  lat,  long,  seismic, 
lastinsp,  nextinsp,  yearcmpl,  category,  subcatl,  subcat2,  cat_comm, 
updtdate,  startdate,  schedcmpl,  cngdstl,  region,  basin,  nearcity,  dis¬ 
tance,  population,  strhgt,  norcap,  hazardcode,  spilltype,  spillwid, 
spilldis,  volmat,  numlocks,  engr,  const,  sate2,  lenlock,  widlock, 
miscode,  cost,  eap,  eap  i,  eap  o,  eap_n,  eap  nl,  eap_n2,  eap_e, 
eap_el,  eap_e2,  eap_coram,  rel_well,  rel_welll,  rel_well2,  drain, 
instr,  instr_mon,  water_qual,  fed,  fed_power,  fed_prop,  nfed. 
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Figure  19.  Application's  E-R  diagram 


nfed_power,  nfed_prop,  fercno,  licensee,  total_insp,  insp_freq, 
surf  area,  drain  area,  poc,  phone). 

•  Auxdara  (#id,  auxname,  auxtype,  auxstrht,  auxcrlen,  auxvol). 

•  Coeinspd  (#inspdate,  #id). 

•  Div_dist  (#div_code,  #dist_code,  division,  district). 

•  Coelock2  (#id,  loc_len2,  loc_wid2). 

The  entities  Auxdam  and  Div_dist  have  compound  keys  because  more  than 
one  attribute  is  necessary  to  identify  one  element  of  the  entities.  It  is  not  the 
objective  of  this  report  to  explain  the  significance  of  all  attributes. 
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Structure  Chart 


As  mentioned  in  Chapter  4,  the  Structure  Chart  permits  a  creation  of  a 
hierarchy  between  the  program  modules. 

Figure  20  shows  the  main' structure  of  the  Corps  of  Engineers  National 
Dam  Inventory  Data  Update  Program.  Figures  21  and  22  show  details  and 
how  they  are  linked  with  the  main  structure  through  page  connectors  like  Cl, 
C2,  CS,  Cl,  and  CM. 

Table  1  describes  all  program  functions  and  procedures  with  their  purposes 
and  parameters  used. 
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Figure  20.  Main  structure  chart 
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Figure  21.  Structure  chart  with  page  connectors  Cl,  C2,  and  CS 
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Figure  22.  Structure  chart  with  page  connectors  Cl  and  CM 
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Table  1 

Procedures  and  Functions  of  Application 

Name 

Purpose 

Type 

Parameters 

COEID1 

Screen  1  of  COE  dams  data  -  id  and 
location 

Procedure 

COEID2 

Screen  2  of  COE  dams  data  -  id  and 
location 

Procedure 

COEINSP 

Screen  4  of  COE  dams  data  -  inspection 
artd  hazard 

Procedure 

COEMISC 

Screen  5  of  COE  dams  data  - 
miscellaneous 

Procedure 

COESTAT 

Screen  3  of  COE  dams  data  -  statistics 

Procedure 

DATACHEK 

Check  dam  record 

Procedure 

DAMSELEC 

Select  dam  with  cursor 

Procedure 

DISTCHK 

Validate  usacedistrict 

Logic  function 

lnput_var 

DISTSELECT 

Select  district  with  cursor 

Procedure 

DIVCHK 

Validate  usace  division 

Logic  function 

Input  var 

DIVSELECT 

Select  division  with  cursor 

Procedure 

EAPDATA 

Window  routine  for  eap  data 

Procedure 

EMERCHK 

Validate  emergency  action  plan  and 
prompt  and  display  EAP  data 

Logic  function 

lnput_var 

FPWRCHK 

Prompt  ar>d  display  data  for  Federal 
regulated  power  installation. 

Logic  function 

lnput_var 

FPWRDATA 

Window  routine  for  Federal  power  data 

Procedure 

FTRUPDT 

Update  auxiliary  features  data 

Procedure 

HA2DCHK 

Validate  downstream  hazard  code 

Logic  function 

Input  var 

HELP 

Provide  aid  and/or  extra  information  to 
user  and  not  represented  in  the  struc¬ 
ture  chart 

Procedure 

INSPDT 

Replace  nextinsp  with  new  value 

Logic  function 

New_var 

New  var2 

INSPFRQ 

Replace  nextinsp  with  new  value  based 
on  change  in  frequency 

Logic  function 

New_var 

New  var2 

INSTRCHK 

Prompt  and  display  instrumentation 
data 

Logic  function 

lnput_var 

INSTRDATA 

Window  routine  for  instrumentation 
data 

Procedure 

NFPWRCHK 

Prompt  and  display  data  for  non-Federal 
regulated  power  installation. 

Logic  function 

lnput_var 

NFPWRDATA 

Window  routine  for  non-Federal  power 
data 

Procedure 

OWNRCHK 

Validate  type  of  owner 

Logic  function 

lnput_var 

POCDATA 

Window  routine  for  poc  data  if  category 
<  >  "Corps" 

Procedure 

PURPCHK 

Validate  purpose  of  dam 

Logic  function 

Input  var 

SCAT1CHK 

Validate  subcategory  No.  1 

Logic  function 

Input  var 

SCAT2CHK 

Validate  subcategory  No.  2 

Logic  function 

lnput_var 

1  (Continu0d) 
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Table  1  (Concluded) 


Nante 

Purpose 

Type 

SCRSELECT 

Determine  the  screen  to  display 

Procedure 

SEISCHK 

Validate  seismic  zone 

Logic  function 

SPILLCHK 

Validate  type  of  spillway 

Logic  function 

STATECHK 

Validate  state  code 

Logic  function 

STATELOAD 

Load  state  codes  into  an  array  (starr) 

Procedure 

TYPECHK 

Validate  type  of  dam 

Logic  function 

VALINPUT 

Validate  data  input 

Procedure 

Parameter* 
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6  Improvements 


This  chapter  presents  a  Corps  of  Engineers  National  Inventory  Data  Update 
Program  improvement  based  on  diagrams  generated  in  Chapter  5.  The  first 
step  of  the  improvement  will  be  on  the  E-R  Diagram,  and  the  second  step  will 
be  on  the  Structured  Chart. 


E-R  Diagram 


Comparing  Figure  19  with  Figure  23,  it  is  possible  to  observe  eight  new 
entities  introduced  in  the  new  E-R  Diagram: 


•  EMPLAN  is  an  emergency  plan  entity  with  two  attributes  as  shown  in 
the  following  tabulation.  A  file  nam^  EMPLAN. DBF  was  created 
with  2  characters  as  the  length  size  of  the  CODEMPLAN  field  and 
15  characters  as  the  length  size  of  the  NAME  field. 


CODEMPLAN 

Y 

N 

NR 

O 


NAME 

Yes 

No 

Not  Required 
Other 


•  HAZARD  is  an  entity  with  four  attributes  as  shown  in  the  following 
tabulation.  A  file  named  HAZARD. DBF  was  created  with  1  character 
as  the  length  size  of  the  CATEGORY  field,  12  characters  as  the 
length  size  of  the  NAME  field,  15  characters  for  the  LOSS_LIFE 
field,  and  15  characters  for  the  ECONO_LOSS  field. 


CATEGORY  NAME 
L  Low 

S  Significant 

H  High 

O  Other 


LOSS_LIFE 
None  Expected 
Few 

More  Than  Few 


ECONO_LOSS 

Minimal 

Appreciable 

Excessive 
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STATE 


AUXDAM 


C0EL0CK2 


COEINSP 


TYPE 


Figure  23.  E-R  diagram  improved 


•  PURPOSE  is  an  entity  with  two  attributes  as  shown  in  the  following 
tabulation.  A  file  named  PURPOSE.DBF  was  created  with  1  charac¬ 
ter  as  the  length  size  of  the  CODPURPOSE  field  and  45  characters  as 
the  length  size  of  the  NAMEPURPOS  field. 
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CODPURPOSE 

I 

H 

C 

N 

S 

R 

P 

F 

D 

T 

O 


NAMEPURPOS 

Irrigation 

Hydroelectric 

Flood  Control  and  Storm  Water  Management 

Navigation 

Water  Supply 

Recreation 

Fire  Protection,  Stock,  or  Small  Farm  Pond 

Fish  and  Wildlife  Pond 

Debris  Control 

Tailings 

Other 


•  SEISMIC  is  an  entity  with  three  attributes  as  shown  in  the  following 
tabulation.  A  file  named  SEISMIC. DBF  was  created  with  1  character 
as  the  length  size  of  the  ZONE  field,  10  characters  as  the  length  size 
of  the  DAMAGE  field,  and  5  characters  for  the  COEFFICIENT  field. 


ZONE 

DAMAGE 

COEFFICIENT 

0 

None 

0.0000 

1 

Minor 

0.025 

2 

Moderate 

0.050 

3 

Major 

0.100 

4 

Great 

0.150 

•  SPILLWAY  is  an  entity  with  two  attributes  as  shown  in  the  following 
tabulation.  A  file  named  SPILLWAY. DBF  was  created  with  1  charac¬ 
ter  as  the  length  size  of  the  TYPE  field  and  15  characters  as  the  length 
size  of  the  NAME  field. 


TYPE 

NAME 

C 

Controlled 

U 

Uncontrolled 

N 

None 

0 

Other 

STATUS  is  an  entity  with  two  attributes  as  shown  in  the  following 
tabulation.  A  file  named  STATUS. DBF  was  created  with  1  character 

as  the  length  size  of  the  CODSTATUS  field  and  30  characters  as  the 

length  size  of  the 

NAMESTATUS  field. 

CODSTATUS 

NAMESTATUS 

D 

Corps  Designed 

C 

Corps  Constructed 

0 

Operational 

F 

Regulated  for  Flood  Control 

N 

Regulated  for  Navigation 
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•  TYPE  is  an  entity  with  two  attributes  as  shown  in  the  following  tabu¬ 
lation.  A  file  named  TYPE. DBF  was  created  with  2  characters  as  the 
length  size  of  the  CODTYPE  field  and  15  characters  as  the  length  size 
of  the  NAMETYPE  field. 


CODTYPE 

NAMETYPE 

RE 

Earthfill 

ER 

Rockfill 

PG 

Gravity 

CB 

Buttress 

VA 

Arch 

MV 

Multi-arch 

CN 

Concrete 

MS 

Masonry 

ST 

Stone 

TC 

Timber  Crib 

OT 

Other 

•  STATE  is  an  entity  with  two  attributes  as  shown  in  the  following 
tabulation.  A  file  named  STATE.DBF  was  created  with  2  characters 
as  the  length  size  of  the  CODSTATE  field  and  15  characters  as  the 
length  size  of  the  NAME  field. 

The  entities  described  were  created  because  they  have  their  own  attributes. 
One  relationship  with  CORPS  can  be  established,  and  a  maintenance  file  can 
be  realized  through  DataBaseUtility(DBU)  that  enables  insert,  edit,  delete,  or 
filter  data.  As  an  example,  the  original  program  presents  an  array  with  three 
disadvantages  of  this  solution  described  as: 

•  RAM  memory  allocation  because  the  array  remains  in  the  main 
memory  during  run  time. 

•  No  simple  reutilization  array  because  with  the  file  STATE,  it  can  be 
easily  reutilized  by  any  other  program. 

•  Difficult  maintenance  because  if  a  new  state  is  created  or  if  it  is  neces¬ 
sary  to  restrict  a  state,  the  insert  or  the  filter  can  be  easily  and  very 
quickly  realized  through  the  DBU  without  change  code. 

A  second  example  is  related  with  the  creation  of  the  SEISMIC  file.  This 
entity  has  three  attributes:  zone,  damage,  and  coefficient,  and  one  file  can  be 
created.  A  new  zone  creation  or  a  coefficient  change  in  the  file  through  DBU 
is  easier  than  changing  program  code  lines,  and  the  file  is  available  to  a  future 
reutilization  in  another  program.  All  the  other  files  created  have  the  same 
justification. 

Figure  19  shows  two  distinct  entities,  DIVISION  and  DISTRICT.  A  relat¬ 
ionship  between  the  entities  was  established  through  a  foreign  key  so  that  the 
stored  data  quantity  decreased  because  the  division  name  and  code  were 
repeated  for  all  districts  subordinated.  It  is  important  to  emphasize  that 
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Division  and  District  are  different  entities  with  owner  attributes.  The  cor¬ 
respondent  files  are  DIVISION.DBF(#CODDIV,  NAMEDIV)  and  DIS- 
TRICT.DBF  (#CODDIST,  NAMEDIT,CODDIV). 

This  proposal  splits  the  file  CORPS. DBF  at  11  files  so  that  each  file  corre¬ 
sponds  to  one  Division.  The  CORPS. DBF  has  approximately  400  Kb  and, 
with  the  split  process,  the  larger  file  occupies  approximately  120  Kb  of 
secondary  memory.  This  enables  a  faster  database  process.  New  files  are 
listed: 


LMV.DBF 

Lower  Mississippi  Valley  Division 

MRD.DBF 

Missouri  River  Division 

NAD.DBF 

North  Atlantic  Division 

NCD.DBF 

North  Central  Division 

NPD.DBF 

North  Pacific  Division 

ORD.DBF 

Ohio  River  Division 

SAD.DBF 

South  Atlantic  Division 

SPD.DBF 

South  Pacific  Division 

NED.DBF 

New  England  Division 

POD.DBF 

Pacific  Ocean  Division 

SWD.DBF 

Southwestern  Division 

Structure  Chart 

Two  improvements  are  suggested  to  the  structure  charts  shown  in  Fig¬ 
ures  20,  21,  and  22. 

•  Decrease  the  control  structure  (if/while/case)  levels  as  shown  in  Fig¬ 
ure  20  through  new  modules  called  by  the  main  module  so  that  a 
better  modular  program  structure  may  be  developed. 

Packing  the  program  at  more  than  one  source  font  for  easier 
maintenance. 


Control  Structure  Levels  Decreasing 


The  level  number  as  shown  in  Figure  20  was  decreased,  and  a  better  mod¬ 
ular  structure  is  proposed.  Figure  24  shows  the  new  structured  charts  for  the 
Corps  of  Engineers  National  Dam  Inventory  Data  Update  Program.  Table  2 
shows  comparisons  between  the  old  structure  and  the  new  one,  with  advan¬ 
tages  of  the  main  new  structure. 

It  is  possible  to  list  any  new  modular  structure  consequence: 

V 
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•  The  public  variables  minor  number  permits  using  a  less  RAM,  and 
local  variables  were  used  because  they  only  are  allocated  in  RAM 
when  the  procedure  where  they  are  defined  is  allocated. 

•  No  use  of  unconditional  deviation  command,  like  the  GOTO  com¬ 
mand,  because  it  isn’t  a  well-structured  programming  technique. 

•  A  small  main  program  enables  initialization  procedures  and  main 
select  menu. 

•  Approximately  30-percent  line  code  reduction. 

•  Reduction  from  8  to  1  control  structure  in  the  main  program  allows  a 
better  maintenance. 


Figure  24.  New  structure  charts  for  National  Dam  Inventory  Update  Program 
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Table  2 

Old  and  New  Structure  Program  Comparisons 

ham 

Old  Structure 

New  Structure 

Advantages 

Main  program  size 

2,550  lines 

42  lines 

-  Easy  maintenance 

Main  program  control 

structures 

(if/while/case/for) 

8 

1 

-  Easy  maintenance 

-  Better  modular 

structure 

Programs 
(PRG  extension) 

CDAMS  (2,550  lines) 
COEPRINT  (916  lines) 
COEINDEX  (42  lines) 

DAMCE  (42  lines) 

DAM  (639  lines) 

DAMBEG  (70  lines) 
DAMDIV  (69  lines) 
DAMDBSE  (114  lines) 
DAMPRINT  (1,007  lines) 
DAMLIB  (370  lines) 
DAMMNT(50  lines) 

-  Easier  development 

-  Easier  maintenance 

-  Code  reutilization 

Total  Program  Lines 

3,508 

2,361 

-  Less  secondary 
memory 

Main  file  index  time' 

10  s 

3  s 

-  Faster 

GOTO  Commands 

6 

0 

-  Unconditional  devia¬ 
tion  is  not  a  good 
structure  command 

Global  variables 

10 

2 

-  Using  less  RAM 

Arrays 

2 

0 

-  Using  less  RAM 

Functions 

Add 

Edit 

Report 

Add 

Edit 

Report 

Database  Consult 

Delete 

IrKfex  maintenance 

-  More  functionality 

'  486  SX/IBM  Processor 

Program  Packing 


The  Corps  of  Engineers  National  Dam  Inventory  Data  Update  main  file  has 
2,550  code  lines  that  require  a  hard  program  maintenance  when  an  alteration 
is  necessary.  This  difficulty  is  because  the  first  task  will  be  to  locate  the 
function  needing  alterations,  and  the  second  one  will  be  to  recompile 
2,550  code  lines.  Packing  is  a  technique  that  enables  the  structured  chart  to 
be  divided  so  that  the  modules,  procedures,  or  functions,  can  be  arranged  as 
needed  at  source  files.  This  process  enables  source  files  to  be  generated  with 
specific  objectives.  For  example,  a  source  file  called  DAMPRINT.PRG 
combines  the  procedures  that  generate  reports.  It  is  possible  to  run  a  discon¬ 
nected  file  test.  After  a  successful  run,  the  source  files  can  be  combined  into 
one  executable  program. 

Figure  25  shows  the  source  files  to  the  proposed  packing  that  are: 
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Figure  25.  Proposed  program  packing  source  files 


•  DAMCE.PRG,  main  source  file. 

•  DAMBEG.PRG,  with  initialization  procedures. 

•  DAMDFV.PRG,  with  Division  and  District  select  procedures. 

•  DAM.PRG,  with  add,  edit,  and  delete  procedures. 

•  DAMDBSE.PRG,  with  TBrowse  consult  procedure. 

•  DAMPRINT.PRG,  with  report  procedures. 

•  DAMMNG.PRG,  with  management  procedures  like  index  file  process. 
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•  DAMLIB.PRG,  with  support  functions  like  a  message  sending. 

The  file  number  might  indicate  a  maintenance  problem,  although  it  is  not. 
If  a  programmer  has  a  report  problem,  he  selects  the  DAMPRINT.PRG  file, 
makes  the  changes,  compiles  it  separately,  and  later  links  it  with  the  others 
files.  The  modular  structure  enables  a  better  code  reutilization  as  well.  The 
file  DAMLIB.PRG  is  an  example  that  contains  all  generic  use  procedures  and 
functions  that  can  be  reutilized  in  other  programs.  Another  example  is  the 
MENUPRINT  procedure  located  in  the  DAM.PRG  file.  A  report  menu  can 
be  generated,  and  with  few  adaptations,  it  is  possible  to  generate  another 
specific  menu. 
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7  Conclusion 


The  E-R  Diagram  and  Structured  Chart  are  easy-to-use  tools,  and  they 
permit  an  excellent  overview  of  the  data  and  functions  program.  Their  use 
enables  us  to  create  a  minimum  documentation  with  the  following  advantages; 

•  A  constant  program  structure  overview. 

•  A  program  development  with  suggestions  for  a  better  structure. 

•  An  excellent  database  and  function  graphical  interface  between  user 
and  programmer  that  permits  participation  in  the  program 
development. 

•  A  simple  maintenance  for  program  life  by  all  users. 

•  A  database  and/or  functions  reutilization  in  others  programs. 

A  suggested  life  cycle  to  develop  structured  programs  follows: 

Analysis  Phase  Activities: 

•  List  objectives  of  the  system. 

•  Study  problem  defined  in  the  objectives. 

•  Define  DATABASE  using  the  E-R  Diagram  (if  necessary). 

Project  Phase  Activities: 

•  Program  structure  charts  design. 

•  Program  specifications  in  the  language  to  be  used  in  the  system 
development. 

•  Screen  and  report  designs. 

Implementation 

•  Program  codification  in  a  computer. 
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Operation 

•  System  installation  and  maintenance. 

This  work  developed  a  comparison  between  the  original  Corps  of  Engi¬ 
neers  National  Dam  Inventory  Data  Update  Program  and  a  new  version.  The 
two  programs  work  well  and  the  comparative  time  data  presented  in  Table  2 
are  of  little  consequence,  because  the  difference  is  small  and  can  be  decreased 
by  a  more  rapid  processor.  The  source  program  sizes  are  not  important 
because  only  a  few  bytes  are  economized.  The  most  important  difference  in 
this  work  is  the  program  documentation  proposed  through  the  E-R  Diagram 
and  Structured  Chart.  The  E-R  Diagram  is  not  always  necessary  because 
some  scientific  programs  do  not  require  database  files,  but  the  Structured 
Chart  is  applicable  for  all  programs. 

Resuming  all  this  work,  the  E-R  Diagram  and  Structured  Chart  enable  a 
better  database  and  program  MAINTENANCE,  REUTILIZATION,  and 
DOCUMENTATION. 
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